miner,eth: latest block as pending block on rollup #93
Conversation
protolambda
force-pushed
the
fix-pending-block
branch
2 times, most recently
from
6ab0387
to
ed39d5d
Compare
protolambda
force-pushed
the
fix-pending-block
branch
from
ed39d5d
to
fadc776
Compare
|
do not merge until we figure out test-failures in ethereum-optimism/optimism#5736 |
protolambda
force-pushed
the
fix-pending-block
branch
from
fadc776
to
8cc6df7
Compare
|
Figured out the issue: the producing-side of the chain-heads subscription started blocking the forkchoice API. There needs to be at least one subscriber, which is the miner apparently. So instead I now implemented it to drain the produced triggers, without creating pending-block computation work, as well as ignoring incoming news txs, rather than unsubscribing to the tx events. Monorepo e2e tests should pass now. |
protolambda
force-pushed
the
fix-pending-block
branch
from
8cc6df7
to
8a2aa07
Compare
|
cleaned up the diff a little bit more. Ready for review now |
|
@trianglesphere I've created a branch with this change and #95 back ported onto We probably should have a better name for that branch but I wasn't sure what pattern we used so shoved it under I think we should also get both PRs merged into |
There was a problem hiding this comment.
The flag was not included in the list of flags. Failed to start b/c of this.
Line 160 in 6fe4241
Description
This fixes the pending-block behavior to be more compatible with pre-bedrock assumptions: requests for the "pending" block/header get served the "latest" block. This prevents transactions from the tx-pool from being revealed before they are committed to by the sequencer
Additionally this updates other lesser used API endpoints that utilize the "pending" mining state as well:
StateAndHeaderByNumberOrHash) continues processing as "latest" state when the pending state is not available, like in the rollup case.And to prevent unnecessary pending-block computations, the worker in the
minerpackage is changed to:buildPayload, and thus we can disable the pending-block work-triggering parts by draining the events that create those, rather than processing them (innewWorkLoop). Draining is important, as unsubscribing would leave the producing subscription channels filling up, causing the engine API to hang after producing blocks.The engine API will still be initiating tasks for block-building, but does so by merely using the block-building functionality of the worker, not the whole recommit and snapshot thing that still remains from L1 PoW days / pending-block support.
I also suspect that this improves sequencing performance, or at least reduces block-building lag spikes: rebuilding the pending block continuously on the head block which changes every 2 seconds, and re-applying transactions, is expensive. Previously this was worked-around on the sequencer node by setting the pending-block gas limit to be very low (5000 gas to effectively force the pending-blocks to be empty), but now it doesn't try to build it at all anymore, which means there is less contention around the state of the chain and the tx-pool.
Tests
ethereum-optimism/optimism#5736
Replaces #81
Fix CLI-3793